By Paul Cassel, VE3SY 



From Ether to Ethernet 

The merging of wired networks with radio has resulted in a more 
flexible, reliable and portable radio system. Make DX contacts and 
enhance your emergency communications with a hand-held radio. 



"T" a was the last night in December of 
P 2002. Stations in many different 
-A- ^ time zones were being worked from 
North America, while amateurs worldwide 
were bringing in the New Year. Tony, 
VK3JED, in Melbourne, Australia was 
celebrating on the air at 6 o'clock in the 
morning (my time). As midnight ap- 
proached in India, Sam, VU2SBB, was 
busy talking to North America, followed 
by South Africa; then Belgium and the UK. 
It was a thrill to talk to the world from 
home on a hand-held radio. Yes, talk to 
the world with a battery-powered VHF/ 
UHF FM transceiver! 

Amateur Radio has seen many techno- 
logical changes in the last 85 years. First, 
the shift from spark to CW in the '20s; 
next, AM in the early '30s; followed by 
SSB in the '50s. In the '60s, when hams 
started to convert discarded taxi and po- 
lice radios to 2 meters, VHF-FM became 
the rage, with repeaters following. 

Change does not occur without contro- 
versy. "Spark Forever!" was heard in the 
'20s as crystal control and CW ushered in 
the then-new wireless technology. When 
AM first appeared, "brass pounders" felt 
their frequencies were being pirated by the 
new "upstart." Now that Internet linking 
of VHF/UHF Amateur Radio repeaters is 
becoming popular, change is again occur- 
ring, but not without controversy. 

Early experiments linking FM repeat- 
ers using the Internet with Voice Over IP 
(VoIP) were, for the most part, unsuccess- 
ful and none (iPhone was one example) 
ever became popular. Then, in 1998, a ham 
in Vancouver, Canada designed a better, 
more reliable way to do that and it has 
rapidly embraced a worldwide following. 

Dave Cameron, VE7LTD, of Van- 
couver, British Columbia began experi- 
menting with what he called the Internet 
Radio Linking Project or simply IRLP. 
Dave and Michael Illingby, VE7TFD, of 
Vernon, British Columbia, became frus- 
trated with the unreliable operation of 
Windows -based iPhone, VoIP software. 
At that time, all Windows-based Amateur 



Radio linking software used voice con- 
trol (VOX) and it wasn't secure from 
non-amateur access. 

Dave designed and developed the new 
IRLP system using Linux, resulting in an 
ultra-stable operating platform for the 
new software. It now has an installed base 
that is approaching 1000 active nodes and 
is worldwide in scope. With the release 
of Version 3.0 hardware and greatly en- 
hanced software, IRLP continues to grow 
rapidly. (When the author first ordered 
IRLP interface hardware in February 
2001, there were only 63 nodes.) 

What is Voice Over IP? 

Telephone system companies and net- 
work infrastructure suppliers, such as 
Lucent and Nortel, have started promoting 
Voice Over Internet Protocol (VoIP). The 
telephone companies recognized that VoIP 
was an efficient way to merge their tele- 
phone voice and data traffic using the TCP/ 
IP protocol. With an IP-based network, the 
telephone audio is sampled, compressed 
and wrapped into data packets that can be 
routed, bridged and switched alongside 
other data packets flowing through private 
networks and the Internet. With the great 
advances in computer soundcard-based 
software applications, it was just a matter 
of time before reliable VoIP applications 
would be generally available. 

IRLP is not the only VoIP application 
making its way into Amateur Radio. Sys- 
tems such as EchoLink, eQSO and Yaesu 
Wires II allow computer-to-computer or 
computer-to-radio links. IRLP continues 
to build on a philosophy that insists that 
a radio be at each end of an IRLP con- 
tact. Having said that, there is a need for 
PC-radio based networks that the other 
technologies provide. 

Using IRLP 

The technology allows amateurs within 
range of a repeater or simplex station, 
equipped with an IRLP interface, to easily 
link a local repeater to one or more IRLP- 
equipped stations around the world. The lo- 



cal user simply requires a radio with DTMF 
capability and local access information. 

The local linking station is termed a 
node. It's a good idea to contact the sta- 
tion operator before trying to use that sta- 
tion, as some nodes require a pre-access 
code, similar to a phone patch access. One 
should also support the local club or orga- 
nization providing the IRLP link. Refer to 
the list of active nodes at status.irlp.net 
to find a node close to your location. 

The default access requires dialing the 
destination node number. Within a sec- 
ond or two, the called node will identify 
in plain voice with its call sign and loca- 
tion. If the target node is connected, you 
will receive a recording telling you what 
node or reflector the repeater is connected 
to. Optionally, if the target node has en- 
abled its Call Waiting feature, a form of 
voice enabled call display will announce 
that a call has been attempted from your 
node number. 

Multiple repeaters can be linked uti- 
lizing one of over a dozen multi-channel 



What is a Reflector? 

A reflector is nothing more than a 
robust PC accessing a large amount 
of bandwidth and used for a node 
connector or a bridge. These ma- 
chines allow many nodes to be 
linked together in the form of a round 
table or a conference bridge. Only 
one node can talk at a time, although 
all connected nodes receive a copy 
of the received audio. No "doubling" 
is possible on an IRLP system, as 
the first packet to arrive "wins" and 
all other IP packets are ignored until 
the initial station drops the PTT 
circuit. The main reflectors have a 
primary channel and nine sub- 
channels, each with enough capacity 
for a large number of simultaneous 
connections. The main international 
calling channel reflector is 9200 in 
Indianapolis, Indiana. See 
status.irlp.net for a full listing of 
available reflectors. 
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Figure 1 — A block diagram of an IRLP system, showing the PC controller, link radio 
IRLP interface card and repeater. 



IRLP reflectors spread around the world. 
(See sidebar, "What is a Reflector?") 

Audio Delays 

As with any digitally voice-encoded 
system, some audio delays are encoun- 
tered. PTT key-up delays are mainly 
caused by the delay it takes radios to de- 
code the tone squelch information. The 
first thing users need remember is to wait 
about Vz second after pressing the PTT 
switch before talking. (To dispel Internet 
delay myths, once a call has been set up, 
the audio delay over the Internet is about 
the same as one experiences when using 
a digital cell phone.) 

Using IRLP is similar to using your lo- 
cal repeater, except for the aforementioned 
PTT Vi second hold for each access. One 
should also pause about 5 seconds between 
transmissions, to allow for break-ins from 
other operators. Other than your local 
repeater's courtesy tone and ID, you will 
hear no courtesy beeps or CW IDs from 
the other station. This makes IRLP-linked 
calls very transparent and it's difficult to 
know if the other station is across town or 
across the world. The audio quality is just 
that good. A basic block diagram of the 
IRLP system can be seen in Figure 1. 

Audio Path to the Internet 

Now that a connection has been estab- 
lished, the IRLP software takes audio 
from the receiver, which is then fed into 
the LINE IN connector of a PC sound card. 
As soon as a valid COS signal (carrier 
detect) is sensed (from the originating 
link radio), the received audio is con- 



verted into ADPCM (Adaptive Differen- 
tial Pulse Code Modulation, a predictive 
audio compression encoding system) 
digital data. The software then converts 
this data into digital packets; each as- 
signed an IP address for a destination 
node. These packets now flow through the 
Internet to the destination PC where the 
packets are decoded and then sent to the 
sound card LINE OUT jack. This audio is 
then fed to the link radio's transmitter 
audio input. The destination link trans- 
mitter is keyed the instant that valid TCP/ 
IP packets start to arrive. As soon as the 
data stops flowing, the link radio auto- 
matically un-keys, and when the destina- 
tion node replies, the process reverses. 

The Digital Audio Process 

The underlying audio processing tech- 
nology in IRLP is based upon a modified 
freeware application called Speak Freely. 1 
The modified version of Speak Freely 
used by IRLP actually produces the VoIP 
data and decodes the audio. While some 
may be familiar with the Windows -based 
Speak Freely application, IRLP runs the 
Linux version. Since our VHF and UHF 
repeaters do not require anything even 
close to MP3 audio quality, IRLP is 
using VoIP at a low data bit-rate to 
communicate. With the vast majority of 
nodes using cable or DSL modems, the 
32 kb/s data rate for ADPCM is a non- 
issue. Some nodes using dial-up with lim- 
ited bandwidth use a CODEC to utilize 



1 Notes appear on page 32. 



GSM encoding. This encoding format 
requires a data rate of only 17 kB/s, al- 
beit at the cost of some audio quality. It 
is also not as robust as ADPCM with re- 
spect to the handling of packet loss. 

The interface between the radio and 
the PC is performed using a small cus- 
tom logic board connected to the 
computer's parallel printer port. This 
board samples the received audio for 
DTMF signals, detects the link receiver 
COS (carrier operated squelch) for posi- 
tive and instant remote keying, and gen- 
erates the transmit PTT line for the link 
radio. All of the command I/O between 
the PC and the IRLP board is handled by 
a connection to the PC's parallel port. 

The entire system is DTMF (tone) con- 
trollable. The control codes lay imbedded 
in a separate program that reads DTMF 
tones from a DTMF decoder located on the 
interface controller board. These codes 
activate various parts of the software. 
DTMF codes are used to enable/disable 
linking, to open/close links and set identi- 
fiers. Every site has the ability to connect 
directly to any other site, either by using 
direct connections or reflector sites. 

The version 3.0 board also features 
three auxiliary outputs allowing simple 
scripting to command these switches ON 
or OFF. Several node owners have actu- 
ally used the IRLP board and some basic 
bash scripts to write a simple repeater 
controller on the IRLP platform. 

These outputs can sink 2 A of current, 
which is more than adequate for most 
solid-state applications. They can addi- 
tionally drive a high current relay to con- 
trol anything from tower lights to an air 
conditioner. 

Behind the Scenes 

IRLP operates on a very robust dis- 
tributed network infrastructure, which is 
rarely seen or heard from by users. 

Even though the IRLP system is cur- 
rently mature and reliable, the true spirit 
of Amateur Radio implies experimen 
tation, including possible improvements 
and enhancement to the IRLP software. 
Unlike Windows -based systems, IRLP 
updates are automatically downloaded 
to each node without the need for a 
reboot. 

All updates to IRLP software are dis- 
tributed daily during the wee hours of the 
morning without the need for operator 
interaction. When updates are ready for 
distribution, they are simply uploaded to 
the root home IRLP server. The home 
server then notifies the five distributed 
machines around the world that new code 
is ready for download. This is performed 
via rsync, a program providing a very fast 
method for bringing remote files into 
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sync. It is accomplished by sending just 
the differences in files across the IRLP 
network, resulting in a very bandwidth- 
efficient updating process. 

All network nodes can then be brought 
up to the latest software release during 
an early morning file update check. In 
addition, there is no need to re-boot after 
every update, a requirement so familiar 
to Windows users. 

IRLP_BIND for DNS Service 

Most readers who are on the Internet 
will be familiar with the term DNS (Do- 
main Name System). IRLP makes use of 
a custom application modeled after the 
Berkley Internet Name Domain (BIND) 
called IRLP-BIND. Written by VE7LTD, 
IRLP_BIND is similar to Microsoft DNS 
and handles all connect requests by in- 
stantly converting the 4-digit IRLP node 
request into an IP address (see sidebar, 
"What is an IP?") used to find the desti- 
nation node. Before VE7LTD developed 
the IRLP-bind system, an ever-growing 
host file had to be constantly downloaded 
by each node every time the IP changed 
on any node in the system. This resulted 
in a tremendous waste of bandwidth on 
the IRLP server. 

When any connection is attempted 
between IRLP nodes, the originating 
node does a routing lookup from one of 
five servers co-located with major reflec- 
tors distributed around the world. These 
five machines — besides serving as reflec- 
tors and providing the IRLP-bind ser- 
vice — also mirror all of the latest IRLP 
code updates and PGP (Pretty Good Pri- 
vacy — an encryption code) key rings. 
Each local repeater node is assigned one 
of these five servers as a primary server 
based on its node number and geographic 
location in the world. If one server should 
go down, the node just looks at the next 
server down the list. This change short- 
ened the time for new nodes to be recog- 
nized by the rest of the IRLP network and 
reduced the amount of traffic on the 
irlp.net server by many orders of mag- 
nitude. Additionally, no single server fail- 
ure could then take down the routing. 

Even if a route to all five servers were 
to fail, a host file is also stored locally 
with the current IP address of all nodes 
and can be accessed. To keep this local 
host file current, a new host file is down- 
loaded whenever the node sees the IP 
lookup returning a newer address. Even 
if the node makes no calls, a new host 
file is downloaded by each node at 3 AM. 
To prevent a major bandwidth rush on the 
name servers, IRLP takes the difference 
of the Node Number/Modulus 600 and 
uses that as a sleep time to avoid a back- 
log of the daily updates. 
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One of the IRLP install team, Pete, 
VK2YX, points out that the IRLP soft- 
ware designers have gone out of their way 
to accomplish a single goal... that is, to 
make nodes as "maintenance free" as 
possible. From the basic software design 
that handles changing IP addresses, to a 
server back-end that handles completely 
automated software upgrades, updates 
and installation (all during normal sys- 
tem operation), the nodes are designed to 
keep owners from worrying. In spite of 
this good design, Pete volunteers that, 
"Good ideas and new software are always 
welcomed by the software team." 

Many of today's IRLP "standard" fea- 
tures were once just "good ideas" on the 
part of various system owners. Many soft- 
ware designers have "migrated" their 
ideas to the rest of the IRLP fraternity 
via software review and then release, 
through the back-end systems. 

IRLP allows the node owner to cus- 
tomize the node in any way they see fit. 
One can add scripts to do almost any- 
thing, such as: 

• Play ARRL or equivalent news 
broadcasts 

• Play severe weather alerts with text 
to voice freeware 

• Enable a local voicemail system 

• Enable clock/time/date features with 
atomic clock accuracy 

• Build your own features with simple 
scripting 

Authentication Security 
from Hackers 

Unlike systems with minimal, if any, 
security, that allow users access from a 
PC, IRLP uses a system to ensure that each 
call setup is authenticated 100% and au- 
thorized to transmit on the amateur bands. 
The PGP encryption process is used so that 
when a connect request is made, the con- 
necting node and the destination node ex- 
change key challenges. These must 
authenticate or the connection is refused. 

Some details of the IRLP connect re- 
quest authentication are: 

• IRLP uses public/private PGP key 
authentication to encrypt a random mes- 
sage with a 512 bit key. 

• The calling node must authenticate 
with the node called. 

• Once this is done, the called node 
has to prove to the calling node that it is 
in fact who it claims to be. 

• The authentication is bi-directional 
insuring against falsification. 

• The PGP key is created only by the 
IRLP installer and uploaded to the mas- 
ter IRLP key ring. 

• If there is ever a compromised node, 
the ability to remove it from the key ring 
is only a keystroke away. 



What is an IP? 

An IP is like a telephone number 
and is used to address and route 
packets around the Internet. An IP 
address can be recognized by four 
pairs of digits separated by periods 
such as 209.140.206.201. This 
sample IP is the actual numeric ad- 
dress for WWW.ARRL.NET and can 
actually be used in place of the label 
"www.arrl.net." 

There are static and dynamic IPs; 
dynamic is the type consumers are 
provided with. Internet Service Pro- 
viders (ISPs) never have sufficient 
IPs for every client, so they dynami- 
cally assign IPs when one connects 
to the Internet. Some ISPs set very 
short "lease" times so they can pro- 
vide service to all subscribers with a 
fraction of the IPs actually required 
for continuous service. This means 
that, if a machine is idle for more than 
a set time, even though connected to 
the Internet, its IP is reassigned. As 
soon as access is attempted again, 
the ISP assigns a new IP. The IP 
leases can be as short as 10 minutes. 
This was a major challenge to be 
overcome with IRLP. 



Hosting your Own Node 

The actual PC hardware requirements 
associated with this technology are usu- 
ally found in most basements, left over 
from several previous computer upgrades. 
Almost anyone with Internet access can 
host an IRLP node; however, a 24/7 DSL 
or cable modem is recommended, in or- 
der to keep the node quickly abreast of 
updates. 

IRLP can operate quite nicely on a PI 00 
or faster machine equipped with 32 MB 
of RAM, a 1 GB hard drive, a Linux 
friendly network card and an ISA true 
SoundBlaster^ sound card. Unless the 
node is co-located with the repeater, a link 
radio is also required. 

Anyone thinking of hosting a node 
should visit the official IRLP Web site at 
www.irlp.net and review the FAQ sec- 
tions. 2 

It is strongly recommended that, be- 
cause of the duty cycles encountered in 
IRLP, you not use an amateur-class mo- 
bile transceiver for the link radio. When 
connected to a reflector, the link radio is 
in a key down state, as is the repeater. A 
robust surplus commercial transceiver is 
recommended. The GE Phoenix or the 
Motorola M or GM series radios with the 
16-pin option connector make perfect 
link radios. All of these transceivers have 
CTCSS coding capability and they can be 
interfaced without internal access. All the 
required signals at the proper levels are 
available through the option plugs. 




Figure 2 — A typical node with a 
commercial link radio controlled by a PC. 
This is node 3350, Denver, Colorado. The 
link radio shown is a surplus GE Mastr II. 



The most difficult task reported by 
new node owners using non-commercial 
radios is locating a place to take off a 
COS signal. A COS signal that follows 
the squelch activity is necessary in order 
to tell the IRLP node you have audio to 
send to another node. Since most nodes 
utilize CTCSS, this point must only 
change state with a valid CTCSS tone. 
The commercial equipment usually has 
a proper COS signal available from the 
system plug. 

For receive audio it is necessary to 
pick a point unaffected by the local vol- 
ume. This is usually a connection to the 
high side of the volume control or the 
discriminator output. Figure 2 shows a 
typical node with a commercial link ra- 
dio controlled by a PC. 

Without debating the virtues of flat or 
pre-emphasized audio, the transmit audio 
can be fed directly into the microphone 
input. The PTT switching connections 
should be obvious on most equipment. 

All of these signals are accessible 
through the system plugs on most com- 
mercial radios as well as the packet ports 
on some of the newer amateur transceiv- 
ers. However, the COS or CTS signal on 
a number of ham transceivers is usually 
taken off before the CTCSS decoder mak- 
ing the signal unsuitable for link radio 
purposes. With the relatively low cost of 
available surplus commercial equipment, 
that equipment would present a far bet- 
ter choice for fixed link radio service. 

Most nodes are tested and de-bugged 
on a simplex frequency before being used 
to bring IRLP service to a local repeater. 
Before connecting with a local repeater, 
it is important that you devise a method 
to make sure that your repeater's hang 
timer, courtesy tones and CW/Voice IDs 
do not get sent to the IRLP network. 



This can easily be accomplished by 
either modifying the way your repeater's 
CTCSS encoder follows receive activity 
or, if it uses a standard squelch circuit, 
by adding a basic CTCSS encoder. In ei- 
ther case, the encoder needs to be con- 
figured so that it generates tone only 
when the repeater's receiver is actually 
receiving a signal. This is easily accom- 
plished by using the COR (carrier oper- 
ated relay) or COS signal to also control 
the CTCSS encoder, in addition to con- 
trolling the repeater controller. 

Then, with the repeater only sending 
CTCSS tones when a signal is being re- 
ceived at the repeater, the IRLP link ra- 
dio will only generate a COS signal when 
a valid CTCSS tone is present. It is this 
level change that drives the COS input 
on the IRLP board. 

With this simple change, the link ra- 
dio will no longer pass the hang timer, 
the periodic station IDs or any courtesy 
tone when users drop their PTT. With 
these minor changes, those at the other 
end of the IRLP connection will have 
their repeater drop and generate a local 
courtesy tone at the same time the origi- 
nating station drops PTT. There are then 
no superfluous beeps or waiting for the 
other repeater to drop before responding. 

This muting of all such tones and hang 
timers is a hard and fast rule enforced on 
most reflectors. Imagine having 20 or 
more repeaters connected to a reflector 
and having to listen to various local IDs 
every 30 seconds... not a pretty picture. 

Now that we've figured out the RF 
control interface, it's time to order the 
IRLP kit. This includes all of the main 
hardware and software. Transceiver inter- 
face cables are easily fabricated by the 
node operator. 

Full ordering information can be 
found on the IRLP web site at 
www.irlp.net. 

The Installation 

Once you have received your IRLP 
board and the Red Hat 7.3 CD you'll be 
ready to sacrifice an older Pentium I or // 
machine to operate under Linux. Don't 
be intimidated by Linux. The author 
had never used Linux before installing our 
group's first node back in the spring of 
2001. At that time, IRLP was operating 
under Red Hat 6.2 and the install went 
very smoothly. Now, with Red Hat 7.3, 
there is even better support for sound and 
network cards. With the detailed system- 
atic instructions furnished, the installa- 
tion of Linux is quite straightforward 
and is usually accomplished within 30 
minutes. 

Once you are able to telnet out of the 
Linux box to the IRLP server, you are all 



set to download the latest IRLP software 
from the IRLP FTP server. Again, the in- 
stallation is quite straightforward. Part of 
the installation process is the generation of 
the PGP encryption keys used for authenti- 
cation. These keys are emailed to IRLP 
along with the answers to questions only 
the person ordering the IRLP node would 
know. This is used for authentication be- 
fore the PGP keys are added to the IRLP 
key ring. Without the keys being installed 
in the key ring, the new node will be un- 
able to place or receive calls. This feature 
is one of the major-selling security features 
with licensing bodies worldwide. 

As soon as the PGP keys are added, 
the node is operational. 

Great Web Tools 

There are some very powerful Web 
based tools provided to assist the users 
determine real-time status of nodes. Point 
your browser to status.irlp.net and you'll 
see all current network activity showing 
node activity by country. 

You can also see the reflector status 
at a glance. All reflectors and their sub- 
channels are listed, showing the number 
of connected stations on each sub-chan- 
nel. There is also a complete list of all 
nodes worldwide, showing their status. 
The page is dynamically created each 
time it is loaded. By clicking the 
hyperlink header on each column, you 
can sort the ever-growing list on any 
header. The sample listing seen in Fig- 
ures 3 and 4 is sorted by country show- 
ing the status and the length of time each 
node has been in that status. It can be seen 
from the sample that node 8880 in 
McMurdo, Antarctica has only been idle 
for 12 minutes and node 6030 in New 
South Wales, Australia has been con- 
nected to node 1230 in Canada for 3 min- 
utes. From this status page, one can click 
on the node city and view a detailed map 
showing the location of the node. By 
clicking the node number link, one can 
also view other details, such as a detailed 
description of the node owner, frequency 
and CTCSS tone used. 

These user tools were originally de- 
signed by Richard Whitakker, VY1RW, 
and expanded to the current system by 
Kent, N0PSR, with input from Marcus, 
WA2DCI, and other IRLP users. 

Reflector Cops? 

There are some basic rules that must 
be followed when connecting to a reflec- 
tor in order to insure minimal disruption 
to users. For the user, these rules are 
basic, such as a 5-second delay between 
transmissions to allow other stations a 
break-in period. Technical problems on 
a node can cause difficulties for all con- 
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Figure 3 — An example of IRLP Node ID codes and locations, 
sorted by country. 

Figure 4 — A network summary display tool. 
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nected stations. Each reflector typically 
has a small number of reflector "cops" 
ready to drop a node should anything in- 
terfere with normal system operation. 
Blocking a node takes but a few seconds 
and once blocked, the packets from that 
node are ignored. When a node is blocked, 
the system automatically e-mails the node 
owner, explaining the issues surrounding 
the block and the time of the block. When 
the node owner has rectified the problem, 
a reinstatement is requested and the 
firewall block is removed. 3 

Is VoIP Legal? 

Legality depends upon your location. 
US readers should refer to the article by 
Steve Ford, WB8IMY, "VoIP and Ama- 
teur Radio," QST, Feb 2003, pp 44-47. A 
sidebar in that article explains the pos- 
sible implications of US Part 97 regula- 
tions when linking and using VoIP in an 
unattended mode. 

The abbreviated response is that, for 
two repeaters linked via IRLP in unat- 
tended mode, no issue exists as long as 
control of the node is at 222.15 MHz or 
above (with the exception of the CW, SSB 
and amateur satellite portions of the 70- 
cm band). 

In Canada, unattended VHF simplex 
or in-band linking is allowed. However, 
in Germany, linking of any kind, on any 
frequency, has been a regulation issue. 
Until recently, the only DL stations heard 
were those within range of the Belgium 
and Dutch nodes. DARC (the German 
national Amateur Radio society) is work- 
ing to bring regulations in line with cur- 
rent enabling technologies. Recently, a 
node in Nuremberg, DB0VOX, became 
active, so progress is being made. 

Groups and Nets 

The IRLP 4 Kids Net was formed in 
November 2001 to provide a common 
meeting place for young hams to com- 
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municate worldwide via Amateur Radio 
using the IRLP network. 

The Kids Net meets each Saturday at 
0100 UTC (Friday evening in North 
America). That net has been using the Las 
Vegas reflector (9508) that supports both 
dial-up and broadband users. A Yahoo! 
group has been set up at groups.yahoo. 
com/group/irlp4kids/. 

A Canadian YL Net has been started 
using IRLP. This net was described by 
Diane, K2DO, in her QST "YL News" 
column in the January 2003 issue of QST, 
p 92. IRLP allows many groups to meet 
worldwide with no concern about 
propagation or antenna restrictions that 
would normally preclude HF operation. 
The YL Net meets on the 9000 Vancouver 
reflector. 

Listen to IRLP 

Those outside the range of an IRLP 
node can listen-in via a streaming audio 
feed that this author maintains. The easi- 
est way to access this is to go to the 
www.irlp.net Web site and click on the 
Listen Live link. 4 The audio stream is a 
duplicate of the main reflector 9200 chan- 
nel in Indianapolis, Indiana. It allows 
anyone to monitor the reflector audio 
from anywhere an Internet connection is 
available. 

Synergy! 

With the rapidly growing adoption of 
IRLP and other VoIP applications, a new 
world is opening up for both beginners 
and old-timers in Amateur Radio. The 
merging of hand-held radio operation 
with the adaptability and reliability of 
computers brings synergy. Marrying 
wired networks to radio empowers a sys- 
tem whose boundaries are limitless, for 
both emergency and routine communica- 
tions. We've come full circle — merging 
wire with wireless to join our knowledge 
of radio and communications with the 



wired capabilities of the Internet. May 
that marriage prosper, bring many new- 
comers to Amateur Radio and enhance 
operation for all! 

Thanks to the IRLP designer, Dave 
Cameron, VE7LTD, for his assistance in 
preparing this article and for his dedica- 
tion to this project. 

Are You Interested? 

If this article has piqued your inter- 
est, please browse the official IRLP Web 
site at www.irlp.net and feel free to con- 
tact the IRLP designer Dave, VE7LTD, 
at dcameron@irlp.net or the author at 
ve3sy@arrl.net. 

Notes 

1 www.speakfreely.org/The Vol P SpeakFreely 
Web site. 

2 www.irlp.net/ Internet Radio Linking Project 
Web site. 

3 www.kwarc.org/irlp/ IRLP user guidelines 
4 www.kwarc.org/listen/ Streaming audio 
feed of IRLP. 
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